Add `isPlatformVersionAtLeast` and `isOSVersionAtLeast` symbols #138944

madsmtm · 2025-03-25T20:06:20Z

Motivation

When Objective-C code uses @available(...), Clang inserts a call to __isPlatformVersionAtLeast (__isOSVersionAtLeast in older Clang versions). These symbols not being available sometimes ends up causing linker errors. See the new test tests/run-make/apple-c-available-links for a minimal reproducer.

The workaround is to link libclang_rt.osx.a, see e.g. alexcrichton/curl-rust#279. But that's very difficult for users to figure out (and the backreferences to that issue indicates that people are still running into this in their own projects every so often).

For another recent example, this is preventing rustc from using LLVM assertions on macOS, see #62592 (comment) and #134275 (comment).

It is also a blocker for setting the correct minimum OS version in cc-rs, since fixing this in cc-rs might end up introducing linker errors in places where we weren't before (by default, if using e.g. @available(macos 10.15, *), the symbol usually happens to be left out, since clang defaults to compiling for the host macOS version, and thus things seem to work - but the availability check actually compiles down to nothing, which is a huge correctness footgun for running on older OSes).

(My super secret evil agenda is also to expose some variant of @available in Rust's std after rust-lang/rfcs#3750 progresses further, will probably file an ACP for this later. But I believe this PR has value regardless of those future plans, since we'd be making C/Objective-C/Swift interop easier).

Solution

Implement __isPlatformVersionAtLeast and __isOSVersionAtLeast as part of the "public ABI" that std exposes.

This is insta-stable, in the same sense that additions to compiler-builtins are insta-stable, though the availability of these symbols can probably be considered a "quality of implementation" detail rather than a stable promise.

I originally proposed to implement this in compiler-builtins, see rust-lang/compiler-builtins#794, but we discussed moving it to std instead (Zulip thread), which makes the implementation substantially simpler, and we avoid gnarly issues with requiring the user to link libSystem.dylib (since std unconditionally does that).

Note that this does not solve the linker errors for (pure) #![no_std] users, but that's probably fine, if you are using @available to test the OS version on Apple platforms, you're likely also using std (and it is still possible to work around by linking libclang_rt.*.a).

A thing to note about the implementation, I've choosen to stray a bit from LLVM's upstream implementation, and not use _availability_version_check since it has problems when compiling with an older SDK. Instead, we use sysctl kern.osproductversion when available to still avoid the costly PList lookup in most cases, but still with a fall back to the PList lookup when that is not available (with the PList fallback being is similar to LLVM's implementation).

Testing

Apple has a lot of different "modes" that they can run binaries in, which can be a bit difficult to find your bearings in, but I've tried to be as thorough as I could in testing them all.

Tested using roughly the equivalent of ./x test library/std -- platform_version on the following configurations:

macOS 14.7.3 on a Macbook Pro M2
- aarch64-apple-darwin
- x86_64-apple-darwin (under Rosetta)
- aarch64-apple-ios-macabi
- x86_64-apple-ios-macabi (under Rosetta)
- aarch64-apple-ios (using Xcode's "Designed for iPad" setting)
- aarch64-apple-ios-sim (in iOS Simulator, as iPhone with iOS 17.5)
- aarch64-apple-ios-sim (in iOS Simulator, as iPad with iOS 18.2)
- aarch64-apple-tvos-sim (in tvOS Simulator)
- aarch64-apple-watchos-sim (in watchOS Simulator)
- aarch64-apple-ios-sim (in visionOS simulator, using Xcode's "Designed for iPad" setting)
- aarch64-apple-visionos-sim (in visionOS Simulator)
macOS 15.3.1 VM
- aarch64-apple-darwin
- aarch64-apple-ios-macabi
macOS 10.12.6 on an Intel Macbook from 2013
- x86_64-apple-darwin
- i686-apple-darwin
- x86_64-apple-ios (in iOS Simulator)
iOS 9.3.6 on a 1st generation iPad Mini
- armv7-apple-ios with an older compiler

Along with manually inspecting the output of version_from_sysctl() and version_from_plist(), and verifying that they actually match what's expected.

I believe the only real omissions here would be:

aarch64-apple-ios on a newer iPhone that has sysctl available (iOS 11.4 or above).
aarch64-apple-ios on a Vision Pro using Xcode's "Designed for iPad" setting.

But I don't have the hardware available to test those.

@rustbot label O-apple A-linkage -T-compiler -A-meta -A-run-make

try-job: aarch64-apple
try-job: x86_64-apple*

rustbot · 2025-03-25T20:06:26Z

r? @Amanieu

rustbot has assigned @Amanieu.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

rustbot · 2025-03-25T20:06:29Z

This PR modifies run-make tests.

cc @jieyouxu

triagebot.toml has been modified, there may have been changes to the review queue.

cc @davidtwco, @wesleywiser

Amanieu · 2025-04-03T19:30:59Z

r? @tgross35

tgross35 · 2025-04-03T19:59:14Z

Happy to review the implementation, but @Amanieu mind confirming you are okay providing these symbols from std? It seems reasonable to me but as far as I know we don't have anything like this. (Also no other builtins that effectively need std API).

Based on findings in rust-lang/rust#138944, we were previously incorrectly falling back to the product version of the host system.

Amanieu · 2025-04-05T20:01:13Z

It's a bit of a grey area since it's not clear how much it is Rust's responsibility to provide builtin symbols that are only used by C code. Arguably the more "correct" approach is to tell users of C code that we only provide symbols for Rust code and that they need to separately add a dependency on libclang_rt or libgcc, but that is a lot of hassle and thing usually just work without it.

I'm not opposed to adding this in libstd for now, but it might be worth looking into a better story for how to handle builtins that are needed by C code but not Rust code (e.g. emulated TLS, clear_cache, enable_execute_stack, etc).

tgross35

Some initial comments, I still need to take a closer look at the version_from* implementations.

tests/run-make/apple-c-available-links/build.rs

tests/run-make/apple-c-available-links/foo.c

library/std/src/sys/platform_version/darwin/mod.rs

tgross35 · 2025-04-08T23:49:00Z

library/std/src/sys/platform_version/mod.rs

@@ -0,0 +1,12 @@
+//! Runtime lookup of operating system / platform version.
+//!
+//! Related to [RFC 3750](https://github.com/rust-lang/rfcs/pull/3750), which


Cc RFC author @ChrisDenton just so you know this module exists

library/std/src/sys/platform_version/darwin/tests.rs

tgross35 · 2025-04-08T23:59:18Z

library/std/src/sys/platform_version/darwin/compiler_builtins.rs

+//! In Rust's case, while we may provide a feature similar to `@available` in the future, we will
+//! probably do so as a macro exposed by `std` (and not as a compiler builtin). So implementing this
+//! in `std` makes sense, since then we can implement it using `std` utilities, and we can avoid
+//! having `compiler-builtins` depend on `libSystem.dylib`.


Could you mention why we need this as an extern symbol now, before we have the public API?

This would also be a good place to clarify that we aren't making any guarantees about the availability of these symbols and it's possible we remove them in the future for whatever reason.

Could you mention why we need this as an extern symbol now, before we have the public API?

I've rewritten the section a bit.

Making guarantees about the availability warrants discussion though: Let's say I went and removed this code from curl-sys after this PR lands. If Rust later removed these symbols, users of curl-sys would encounter linker errors again.

That is, without some sort of guarantee of the continued availability of these symbols, they're basically useless.

What are your thoughts?

library/std/src/sys/platform_version/darwin/compiler_builtins.rs

madsmtm · 2025-04-09T18:43:50Z

Thanks for the review so far. I've answered or fixed your comments in separate commits, to make it easier for you to review (if you're already halfway through a second review). I can squash once everything is ready.
@rustbot ready

tgross35 · 2025-06-12T19:05:51Z

@bors2 try

Add `__isPlatformVersionAtLeast` and `__isOSVersionAtLeast` symbols ## Motivation When Objective-C code uses ``@available(...)`,` Clang inserts a call to [`__isPlatformVersionAtLeast`](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.0/compiler-rt/lib/builtins/os_version_check.c#L276) (`__isOSVersionAtLeast` in older Clang versions). These symbols not being available sometimes ends up causing linker errors. See the new test `tests/run-make/apple-c-available-links` for a minimal reproducer. The workaround is to link `libclang_rt.osx.a`, see e.g. alexcrichton/curl-rust#279. But that's very difficult for users to figure out (and the backreferences to that issue indicates that people are still running into this in their own projects every so often). For another recent example, this is preventing `rustc` from using LLVM assertions on macOS, see #62592 (comment) and #134275 (comment). It is also a blocker for [setting the correct minimum OS version in `cc-rs`](#136113), since fixing this in `cc-rs` might end up introducing linker errors in places where we weren't before (by default, if using e.g. ``@available(macos` 10.15, *)`, the symbol usually happens to be left out, since `clang` defaults to compiling for the host macOS version, and thus things _seem_ to work - but the availability check actually compiles down to nothing, which is a huge correctness footgun for running on older OSes). (My super secret evil agenda is also to expose some variant of ``@available`` in Rust's `std` after rust-lang/rfcs#3750 progresses further, will probably file an ACP for this later. But I believe this PR has value regardless of those future plans, since we'd be making C/Objective-C/Swift interop easier). ## Solution Implement `__isPlatformVersionAtLeast` and `__isOSVersionAtLeast` as part of the "public ABI" that `std` exposes. **This is insta-stable**, in the same sense that additions to `compiler-builtins` are insta-stable, though the availability of these symbols can probably be considered a "quality of implementation" detail rather than a stable promise. I originally proposed to implement this in `compiler-builtins`, see rust-lang/compiler-builtins#794, but we discussed moving it to `std` instead ([Zulip thread](https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/Provide.20.60__isPlatformVersionAtLeast.60.20in.20.60std.60.3F/with/507880717)), which makes the implementation substantially simpler, and we avoid gnarly issues with requiring the user to link `libSystem.dylib` (since `std` unconditionally does that). Note that this does not solve the linker errors for (pure) `#![no_std]` users, but that's _probably_ fine, if you are using ``@available`` to test the OS version on Apple platforms, you're likely also using `std` (and it is still possible to work around by linking `libclang_rt.*.a`). A thing to note about the implementation, I've choosen to stray a bit from LLVM's upstream implementation, and not use `_availability_version_check` since [it has problems when compiling with an older SDK](llvm/llvm-project#64227). Instead, we use `sysctl kern.osproductversion` when available to still avoid the costly PList lookup in most cases, but still with a fall back to the PList lookup when that is not available (with the PList fallback being is similar to LLVM's implementation). ## Testing Apple has a lot of different "modes" that they can run binaries in, which can be a bit difficult to find your bearings in, but I've tried to be as thorough as I could in testing them all. Tested using roughly the equivalent of `./x test library/std -- platform_version` on the following configurations: - macOS 14.7.3 on a Macbook Pro M2 - `aarch64-apple-darwin` - `x86_64-apple-darwin` (under Rosetta) - `aarch64-apple-ios-macabi` - `x86_64-apple-ios-macabi` (under Rosetta) - `aarch64-apple-ios` (using Xcode's "Designed for iPad" setting) - `aarch64-apple-ios-sim` (in iOS Simulator, as iPhone with iOS 17.5) - `aarch64-apple-ios-sim` (in iOS Simulator, as iPad with iOS 18.2) - `aarch64-apple-tvos-sim` (in tvOS Simulator) - `aarch64-apple-watchos-sim` (in watchOS Simulator) - `aarch64-apple-ios-sim` (in visionOS simulator, using Xcode's "Designed for iPad" setting) - `aarch64-apple-visionos-sim` (in visionOS Simulator) - macOS 15.3.1 VM - `aarch64-apple-darwin` - `aarch64-apple-ios-macabi` - macOS 10.12.6 on an Intel Macbook from 2013 - `x86_64-apple-darwin` - `i686-apple-darwin` - `x86_64-apple-ios` (in iOS Simulator) - iOS 9.3.6 on a 1st generation iPad Mini - `armv7-apple-ios` with an older compiler Along with manually inspecting the output of `version_from_sysctl()` and `version_from_plist()`, and verifying that they actually match what's expected. I believe the only real omissions here would be: - `aarch64-apple-ios` on a newer iPhone that has `sysctl` available (iOS 11.4 or above). - `aarch64-apple-ios` on a Vision Pro using Xcode's "Designed for iPad" setting. But I don't have the hardware available to test those. `@rustbot` label O-apple A-linkage -T-compiler -A-meta -A-run-make try-job: aarch64-apple try-job: x86_64-apple

rust-bors · 2025-06-12T19:05:55Z

⌛ Trying commit 7852c5c with merge d3ba066…

To cancel the try build, run the command @bors2 try cancel.

rust-bors · 2025-06-12T19:07:50Z

💔 Test failed

CI ❌

tgross35

Thanks, this looks pretty great to me! r=me with a green try job, tiny nit here, and a squash.

Good idea, I've done that now. This does have a very slight cost that CFRelease is now looked up multiple times - but again, this code is used infrequently and only once, so it's probably fine.

This crossed my mind too - it would be possible to cache the symbols in the handle struct, but agreed it's probably not worth it here.

library/std/src/sys/platform_version/darwin/core_foundation.rs

madsmtm · 2025-06-12T23:31:46Z

Have squashed and fixed the nit, will try to get a green try job:
@bors2 try

I think we still need to discuss the guarantees we want to give by providing this, see the thread in #138944 (comment).

rust-bors · 2025-06-12T23:31:50Z

⌛ Trying commit 516742a with merge 813f50b…

To cancel the try build, run the command @bors2 try cancel.

Add `__isPlatformVersionAtLeast` and `__isOSVersionAtLeast` symbols ## Motivation When Objective-C code uses ``@available(...)`,` Clang inserts a call to [`__isPlatformVersionAtLeast`](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.0/compiler-rt/lib/builtins/os_version_check.c#L276) (`__isOSVersionAtLeast` in older Clang versions). These symbols not being available sometimes ends up causing linker errors. See the new test `tests/run-make/apple-c-available-links` for a minimal reproducer. The workaround is to link `libclang_rt.osx.a`, see e.g. alexcrichton/curl-rust#279. But that's very difficult for users to figure out (and the backreferences to that issue indicates that people are still running into this in their own projects every so often). For another recent example, this is preventing `rustc` from using LLVM assertions on macOS, see #62592 (comment) and #134275 (comment). It is also a blocker for [setting the correct minimum OS version in `cc-rs`](#136113), since fixing this in `cc-rs` might end up introducing linker errors in places where we weren't before (by default, if using e.g. ``@available(macos` 10.15, *)`, the symbol usually happens to be left out, since `clang` defaults to compiling for the host macOS version, and thus things _seem_ to work - but the availability check actually compiles down to nothing, which is a huge correctness footgun for running on older OSes). (My super secret evil agenda is also to expose some variant of ``@available`` in Rust's `std` after rust-lang/rfcs#3750 progresses further, will probably file an ACP for this later. But I believe this PR has value regardless of those future plans, since we'd be making C/Objective-C/Swift interop easier). ## Solution Implement `__isPlatformVersionAtLeast` and `__isOSVersionAtLeast` as part of the "public ABI" that `std` exposes. **This is insta-stable**, in the same sense that additions to `compiler-builtins` are insta-stable, though the availability of these symbols can probably be considered a "quality of implementation" detail rather than a stable promise. I originally proposed to implement this in `compiler-builtins`, see rust-lang/compiler-builtins#794, but we discussed moving it to `std` instead ([Zulip thread](https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/Provide.20.60__isPlatformVersionAtLeast.60.20in.20.60std.60.3F/with/507880717)), which makes the implementation substantially simpler, and we avoid gnarly issues with requiring the user to link `libSystem.dylib` (since `std` unconditionally does that). Note that this does not solve the linker errors for (pure) `#![no_std]` users, but that's _probably_ fine, if you are using ``@available`` to test the OS version on Apple platforms, you're likely also using `std` (and it is still possible to work around by linking `libclang_rt.*.a`). A thing to note about the implementation, I've choosen to stray a bit from LLVM's upstream implementation, and not use `_availability_version_check` since [it has problems when compiling with an older SDK](llvm/llvm-project#64227). Instead, we use `sysctl kern.osproductversion` when available to still avoid the costly PList lookup in most cases, but still with a fall back to the PList lookup when that is not available (with the PList fallback being is similar to LLVM's implementation). ## Testing Apple has a lot of different "modes" that they can run binaries in, which can be a bit difficult to find your bearings in, but I've tried to be as thorough as I could in testing them all. Tested using roughly the equivalent of `./x test library/std -- platform_version` on the following configurations: - macOS 14.7.3 on a Macbook Pro M2 - `aarch64-apple-darwin` - `x86_64-apple-darwin` (under Rosetta) - `aarch64-apple-ios-macabi` - `x86_64-apple-ios-macabi` (under Rosetta) - `aarch64-apple-ios` (using Xcode's "Designed for iPad" setting) - `aarch64-apple-ios-sim` (in iOS Simulator, as iPhone with iOS 17.5) - `aarch64-apple-ios-sim` (in iOS Simulator, as iPad with iOS 18.2) - `aarch64-apple-tvos-sim` (in tvOS Simulator) - `aarch64-apple-watchos-sim` (in watchOS Simulator) - `aarch64-apple-ios-sim` (in visionOS simulator, using Xcode's "Designed for iPad" setting) - `aarch64-apple-visionos-sim` (in visionOS Simulator) - macOS 15.3.1 VM - `aarch64-apple-darwin` - `aarch64-apple-ios-macabi` - macOS 10.12.6 on an Intel Macbook from 2013 - `x86_64-apple-darwin` - `i686-apple-darwin` - `x86_64-apple-ios` (in iOS Simulator) - iOS 9.3.6 on a 1st generation iPad Mini - `armv7-apple-ios` with an older compiler Along with manually inspecting the output of `version_from_sysctl()` and `version_from_plist()`, and verifying that they actually match what's expected. I believe the only real omissions here would be: - `aarch64-apple-ios` on a newer iPhone that has `sysctl` available (iOS 11.4 or above). - `aarch64-apple-ios` on a Vision Pro using Xcode's "Designed for iPad" setting. But I don't have the hardware available to test those. `@rustbot` label O-apple A-linkage -T-compiler -A-meta -A-run-make try-job: aarch64-apple try-job: x86_64-apple*

rust-bors · 2025-06-13T00:24:43Z

💔 Test failed

CI ❌

madsmtm · 2025-06-13T01:34:01Z

Fixed two rustdoc link warnings ("bare URLs are not automatically turned into clickable links").
@bors2 try

rust-bors · 2025-06-13T01:34:04Z

⌛ Trying commit 516742a with merge 9ddcf15…

To cancel the try build, run the command @bors2 try cancel.

Add `__isPlatformVersionAtLeast` and `__isOSVersionAtLeast` symbols ## Motivation When Objective-C code uses ``@available(...)`,` Clang inserts a call to [`__isPlatformVersionAtLeast`](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.0/compiler-rt/lib/builtins/os_version_check.c#L276) (`__isOSVersionAtLeast` in older Clang versions). These symbols not being available sometimes ends up causing linker errors. See the new test `tests/run-make/apple-c-available-links` for a minimal reproducer. The workaround is to link `libclang_rt.osx.a`, see e.g. alexcrichton/curl-rust#279. But that's very difficult for users to figure out (and the backreferences to that issue indicates that people are still running into this in their own projects every so often). For another recent example, this is preventing `rustc` from using LLVM assertions on macOS, see #62592 (comment) and #134275 (comment). It is also a blocker for [setting the correct minimum OS version in `cc-rs`](#136113), since fixing this in `cc-rs` might end up introducing linker errors in places where we weren't before (by default, if using e.g. ``@available(macos` 10.15, *)`, the symbol usually happens to be left out, since `clang` defaults to compiling for the host macOS version, and thus things _seem_ to work - but the availability check actually compiles down to nothing, which is a huge correctness footgun for running on older OSes). (My super secret evil agenda is also to expose some variant of ``@available`` in Rust's `std` after rust-lang/rfcs#3750 progresses further, will probably file an ACP for this later. But I believe this PR has value regardless of those future plans, since we'd be making C/Objective-C/Swift interop easier). ## Solution Implement `__isPlatformVersionAtLeast` and `__isOSVersionAtLeast` as part of the "public ABI" that `std` exposes. **This is insta-stable**, in the same sense that additions to `compiler-builtins` are insta-stable, though the availability of these symbols can probably be considered a "quality of implementation" detail rather than a stable promise. I originally proposed to implement this in `compiler-builtins`, see rust-lang/compiler-builtins#794, but we discussed moving it to `std` instead ([Zulip thread](https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/Provide.20.60__isPlatformVersionAtLeast.60.20in.20.60std.60.3F/with/507880717)), which makes the implementation substantially simpler, and we avoid gnarly issues with requiring the user to link `libSystem.dylib` (since `std` unconditionally does that). Note that this does not solve the linker errors for (pure) `#![no_std]` users, but that's _probably_ fine, if you are using ``@available`` to test the OS version on Apple platforms, you're likely also using `std` (and it is still possible to work around by linking `libclang_rt.*.a`). A thing to note about the implementation, I've choosen to stray a bit from LLVM's upstream implementation, and not use `_availability_version_check` since [it has problems when compiling with an older SDK](llvm/llvm-project#64227). Instead, we use `sysctl kern.osproductversion` when available to still avoid the costly PList lookup in most cases, but still with a fall back to the PList lookup when that is not available (with the PList fallback being is similar to LLVM's implementation). ## Testing Apple has a lot of different "modes" that they can run binaries in, which can be a bit difficult to find your bearings in, but I've tried to be as thorough as I could in testing them all. Tested using roughly the equivalent of `./x test library/std -- platform_version` on the following configurations: - macOS 14.7.3 on a Macbook Pro M2 - `aarch64-apple-darwin` - `x86_64-apple-darwin` (under Rosetta) - `aarch64-apple-ios-macabi` - `x86_64-apple-ios-macabi` (under Rosetta) - `aarch64-apple-ios` (using Xcode's "Designed for iPad" setting) - `aarch64-apple-ios-sim` (in iOS Simulator, as iPhone with iOS 17.5) - `aarch64-apple-ios-sim` (in iOS Simulator, as iPad with iOS 18.2) - `aarch64-apple-tvos-sim` (in tvOS Simulator) - `aarch64-apple-watchos-sim` (in watchOS Simulator) - `aarch64-apple-ios-sim` (in visionOS simulator, using Xcode's "Designed for iPad" setting) - `aarch64-apple-visionos-sim` (in visionOS Simulator) - macOS 15.3.1 VM - `aarch64-apple-darwin` - `aarch64-apple-ios-macabi` - macOS 10.12.6 on an Intel Macbook from 2013 - `x86_64-apple-darwin` - `i686-apple-darwin` - `x86_64-apple-ios` (in iOS Simulator) - iOS 9.3.6 on a 1st generation iPad Mini - `armv7-apple-ios` with an older compiler Along with manually inspecting the output of `version_from_sysctl()` and `version_from_plist()`, and verifying that they actually match what's expected. I believe the only real omissions here would be: - `aarch64-apple-ios` on a newer iPhone that has `sysctl` available (iOS 11.4 or above). - `aarch64-apple-ios` on a Vision Pro using Xcode's "Designed for iPad" setting. But I don't have the hardware available to test those. `@rustbot` label O-apple A-linkage -T-compiler -A-meta -A-run-make try-job: aarch64-apple try-job: x86_64-apple*

madsmtm · 2025-06-13T01:35:02Z

I meant another commit.

@bors2 try cancel
@bors2 try

rust-bors · 2025-06-13T01:35:05Z

Try build cancelled. Cancelled workflows:

https://github.com/rust-lang/rust/actions/runs/15624394507

rust-bors · 2025-06-13T01:35:07Z

⌛ Trying commit 5ec7157 with merge 2008cdd…

To cancel the try build, run the command @bors2 try cancel.

Add `__isPlatformVersionAtLeast` and `__isOSVersionAtLeast` symbols ## Motivation When Objective-C code uses ``@available(...)`,` Clang inserts a call to [`__isPlatformVersionAtLeast`](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.0/compiler-rt/lib/builtins/os_version_check.c#L276) (`__isOSVersionAtLeast` in older Clang versions). These symbols not being available sometimes ends up causing linker errors. See the new test `tests/run-make/apple-c-available-links` for a minimal reproducer. The workaround is to link `libclang_rt.osx.a`, see e.g. alexcrichton/curl-rust#279. But that's very difficult for users to figure out (and the backreferences to that issue indicates that people are still running into this in their own projects every so often). For another recent example, this is preventing `rustc` from using LLVM assertions on macOS, see #62592 (comment) and #134275 (comment). It is also a blocker for [setting the correct minimum OS version in `cc-rs`](#136113), since fixing this in `cc-rs` might end up introducing linker errors in places where we weren't before (by default, if using e.g. ``@available(macos` 10.15, *)`, the symbol usually happens to be left out, since `clang` defaults to compiling for the host macOS version, and thus things _seem_ to work - but the availability check actually compiles down to nothing, which is a huge correctness footgun for running on older OSes). (My super secret evil agenda is also to expose some variant of ``@available`` in Rust's `std` after rust-lang/rfcs#3750 progresses further, will probably file an ACP for this later. But I believe this PR has value regardless of those future plans, since we'd be making C/Objective-C/Swift interop easier). ## Solution Implement `__isPlatformVersionAtLeast` and `__isOSVersionAtLeast` as part of the "public ABI" that `std` exposes. **This is insta-stable**, in the same sense that additions to `compiler-builtins` are insta-stable, though the availability of these symbols can probably be considered a "quality of implementation" detail rather than a stable promise. I originally proposed to implement this in `compiler-builtins`, see rust-lang/compiler-builtins#794, but we discussed moving it to `std` instead ([Zulip thread](https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/Provide.20.60__isPlatformVersionAtLeast.60.20in.20.60std.60.3F/with/507880717)), which makes the implementation substantially simpler, and we avoid gnarly issues with requiring the user to link `libSystem.dylib` (since `std` unconditionally does that). Note that this does not solve the linker errors for (pure) `#![no_std]` users, but that's _probably_ fine, if you are using ``@available`` to test the OS version on Apple platforms, you're likely also using `std` (and it is still possible to work around by linking `libclang_rt.*.a`). A thing to note about the implementation, I've choosen to stray a bit from LLVM's upstream implementation, and not use `_availability_version_check` since [it has problems when compiling with an older SDK](llvm/llvm-project#64227). Instead, we use `sysctl kern.osproductversion` when available to still avoid the costly PList lookup in most cases, but still with a fall back to the PList lookup when that is not available (with the PList fallback being is similar to LLVM's implementation). ## Testing Apple has a lot of different "modes" that they can run binaries in, which can be a bit difficult to find your bearings in, but I've tried to be as thorough as I could in testing them all. Tested using roughly the equivalent of `./x test library/std -- platform_version` on the following configurations: - macOS 14.7.3 on a Macbook Pro M2 - `aarch64-apple-darwin` - `x86_64-apple-darwin` (under Rosetta) - `aarch64-apple-ios-macabi` - `x86_64-apple-ios-macabi` (under Rosetta) - `aarch64-apple-ios` (using Xcode's "Designed for iPad" setting) - `aarch64-apple-ios-sim` (in iOS Simulator, as iPhone with iOS 17.5) - `aarch64-apple-ios-sim` (in iOS Simulator, as iPad with iOS 18.2) - `aarch64-apple-tvos-sim` (in tvOS Simulator) - `aarch64-apple-watchos-sim` (in watchOS Simulator) - `aarch64-apple-ios-sim` (in visionOS simulator, using Xcode's "Designed for iPad" setting) - `aarch64-apple-visionos-sim` (in visionOS Simulator) - macOS 15.3.1 VM - `aarch64-apple-darwin` - `aarch64-apple-ios-macabi` - macOS 10.12.6 on an Intel Macbook from 2013 - `x86_64-apple-darwin` - `i686-apple-darwin` - `x86_64-apple-ios` (in iOS Simulator) - iOS 9.3.6 on a 1st generation iPad Mini - `armv7-apple-ios` with an older compiler Along with manually inspecting the output of `version_from_sysctl()` and `version_from_plist()`, and verifying that they actually match what's expected. I believe the only real omissions here would be: - `aarch64-apple-ios` on a newer iPhone that has `sysctl` available (iOS 11.4 or above). - `aarch64-apple-ios` on a Vision Pro using Xcode's "Designed for iPad" setting. But I don't have the hardware available to test those. `@rustbot` label O-apple A-linkage -T-compiler -A-meta -A-run-make try-job: aarch64-apple try-job: x86_64-apple*

rust-bors · 2025-06-13T04:53:55Z

💔 Test failed

CI ❌

madsmtm · 2025-06-13T11:47:01Z

Error was:

foo.c:11:9: error: unrecognized platform name visionos
        visionos 1000.0,
        ^
1 error generated.

Fixed building test with older Clang (modified tests/run-make/apple-c-available-links/*).
@bors2 try

rust-bors · 2025-06-13T11:47:05Z

⌛ Trying commit 779ac2f with merge ea9a6dd…

To cancel the try build, run the command @bors2 try cancel.

Add `__isPlatformVersionAtLeast` and `__isOSVersionAtLeast` symbols ## Motivation When Objective-C code uses ``@available(...)`,` Clang inserts a call to [`__isPlatformVersionAtLeast`](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.0/compiler-rt/lib/builtins/os_version_check.c#L276) (`__isOSVersionAtLeast` in older Clang versions). These symbols not being available sometimes ends up causing linker errors. See the new test `tests/run-make/apple-c-available-links` for a minimal reproducer. The workaround is to link `libclang_rt.osx.a`, see e.g. alexcrichton/curl-rust#279. But that's very difficult for users to figure out (and the backreferences to that issue indicates that people are still running into this in their own projects every so often). For another recent example, this is preventing `rustc` from using LLVM assertions on macOS, see #62592 (comment) and #134275 (comment). It is also a blocker for [setting the correct minimum OS version in `cc-rs`](#136113), since fixing this in `cc-rs` might end up introducing linker errors in places where we weren't before (by default, if using e.g. ``@available(macos` 10.15, *)`, the symbol usually happens to be left out, since `clang` defaults to compiling for the host macOS version, and thus things _seem_ to work - but the availability check actually compiles down to nothing, which is a huge correctness footgun for running on older OSes). (My super secret evil agenda is also to expose some variant of ``@available`` in Rust's `std` after rust-lang/rfcs#3750 progresses further, will probably file an ACP for this later. But I believe this PR has value regardless of those future plans, since we'd be making C/Objective-C/Swift interop easier). ## Solution Implement `__isPlatformVersionAtLeast` and `__isOSVersionAtLeast` as part of the "public ABI" that `std` exposes. **This is insta-stable**, in the same sense that additions to `compiler-builtins` are insta-stable, though the availability of these symbols can probably be considered a "quality of implementation" detail rather than a stable promise. I originally proposed to implement this in `compiler-builtins`, see rust-lang/compiler-builtins#794, but we discussed moving it to `std` instead ([Zulip thread](https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/Provide.20.60__isPlatformVersionAtLeast.60.20in.20.60std.60.3F/with/507880717)), which makes the implementation substantially simpler, and we avoid gnarly issues with requiring the user to link `libSystem.dylib` (since `std` unconditionally does that). Note that this does not solve the linker errors for (pure) `#![no_std]` users, but that's _probably_ fine, if you are using ``@available`` to test the OS version on Apple platforms, you're likely also using `std` (and it is still possible to work around by linking `libclang_rt.*.a`). A thing to note about the implementation, I've choosen to stray a bit from LLVM's upstream implementation, and not use `_availability_version_check` since [it has problems when compiling with an older SDK](llvm/llvm-project#64227). Instead, we use `sysctl kern.osproductversion` when available to still avoid the costly PList lookup in most cases, but still with a fall back to the PList lookup when that is not available (with the PList fallback being is similar to LLVM's implementation). ## Testing Apple has a lot of different "modes" that they can run binaries in, which can be a bit difficult to find your bearings in, but I've tried to be as thorough as I could in testing them all. Tested using roughly the equivalent of `./x test library/std -- platform_version` on the following configurations: - macOS 14.7.3 on a Macbook Pro M2 - `aarch64-apple-darwin` - `x86_64-apple-darwin` (under Rosetta) - `aarch64-apple-ios-macabi` - `x86_64-apple-ios-macabi` (under Rosetta) - `aarch64-apple-ios` (using Xcode's "Designed for iPad" setting) - `aarch64-apple-ios-sim` (in iOS Simulator, as iPhone with iOS 17.5) - `aarch64-apple-ios-sim` (in iOS Simulator, as iPad with iOS 18.2) - `aarch64-apple-tvos-sim` (in tvOS Simulator) - `aarch64-apple-watchos-sim` (in watchOS Simulator) - `aarch64-apple-ios-sim` (in visionOS simulator, using Xcode's "Designed for iPad" setting) - `aarch64-apple-visionos-sim` (in visionOS Simulator) - macOS 15.3.1 VM - `aarch64-apple-darwin` - `aarch64-apple-ios-macabi` - macOS 10.12.6 on an Intel Macbook from 2013 - `x86_64-apple-darwin` - `i686-apple-darwin` - `x86_64-apple-ios` (in iOS Simulator) - iOS 9.3.6 on a 1st generation iPad Mini - `armv7-apple-ios` with an older compiler Along with manually inspecting the output of `version_from_sysctl()` and `version_from_plist()`, and verifying that they actually match what's expected. I believe the only real omissions here would be: - `aarch64-apple-ios` on a newer iPhone that has `sysctl` available (iOS 11.4 or above). - `aarch64-apple-ios` on a Vision Pro using Xcode's "Designed for iPad" setting. But I don't have the hardware available to test those. `@rustbot` label O-apple A-linkage -T-compiler -A-meta -A-run-make try-job: aarch64-apple try-job: x86_64-apple*

rust-bors · 2025-06-13T13:47:49Z

💔 Test failed

CI ❌

Allows users to link to Objective-C code using `@available(...)`.

madsmtm · 2025-06-13T14:18:32Z

Error was:

foo.c:7:10: error: 'TARGET_OS_VISION' is not defined, evaluates to 0 [-Werror,-Wundef-prefix=TARGET_OS_]
    #if !TARGET_OS_VISION
         ^
1 error generated.

Implemented differently with an #ifdef instead.
@bors2 try

rust-bors · 2025-06-13T14:18:36Z

⌛ Trying commit d543096 with merge 7334def…

To cancel the try build, run the command @bors2 try cancel.

Add `__isPlatformVersionAtLeast` and `__isOSVersionAtLeast` symbols ## Motivation When Objective-C code uses ``@available(...)`,` Clang inserts a call to [`__isPlatformVersionAtLeast`](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.0/compiler-rt/lib/builtins/os_version_check.c#L276) (`__isOSVersionAtLeast` in older Clang versions). These symbols not being available sometimes ends up causing linker errors. See the new test `tests/run-make/apple-c-available-links` for a minimal reproducer. The workaround is to link `libclang_rt.osx.a`, see e.g. alexcrichton/curl-rust#279. But that's very difficult for users to figure out (and the backreferences to that issue indicates that people are still running into this in their own projects every so often). For another recent example, this is preventing `rustc` from using LLVM assertions on macOS, see #62592 (comment) and #134275 (comment). It is also a blocker for [setting the correct minimum OS version in `cc-rs`](#136113), since fixing this in `cc-rs` might end up introducing linker errors in places where we weren't before (by default, if using e.g. ``@available(macos` 10.15, *)`, the symbol usually happens to be left out, since `clang` defaults to compiling for the host macOS version, and thus things _seem_ to work - but the availability check actually compiles down to nothing, which is a huge correctness footgun for running on older OSes). (My super secret evil agenda is also to expose some variant of ``@available`` in Rust's `std` after rust-lang/rfcs#3750 progresses further, will probably file an ACP for this later. But I believe this PR has value regardless of those future plans, since we'd be making C/Objective-C/Swift interop easier). ## Solution Implement `__isPlatformVersionAtLeast` and `__isOSVersionAtLeast` as part of the "public ABI" that `std` exposes. **This is insta-stable**, in the same sense that additions to `compiler-builtins` are insta-stable, though the availability of these symbols can probably be considered a "quality of implementation" detail rather than a stable promise. I originally proposed to implement this in `compiler-builtins`, see rust-lang/compiler-builtins#794, but we discussed moving it to `std` instead ([Zulip thread](https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/Provide.20.60__isPlatformVersionAtLeast.60.20in.20.60std.60.3F/with/507880717)), which makes the implementation substantially simpler, and we avoid gnarly issues with requiring the user to link `libSystem.dylib` (since `std` unconditionally does that). Note that this does not solve the linker errors for (pure) `#![no_std]` users, but that's _probably_ fine, if you are using ``@available`` to test the OS version on Apple platforms, you're likely also using `std` (and it is still possible to work around by linking `libclang_rt.*.a`). A thing to note about the implementation, I've choosen to stray a bit from LLVM's upstream implementation, and not use `_availability_version_check` since [it has problems when compiling with an older SDK](llvm/llvm-project#64227). Instead, we use `sysctl kern.osproductversion` when available to still avoid the costly PList lookup in most cases, but still with a fall back to the PList lookup when that is not available (with the PList fallback being is similar to LLVM's implementation). ## Testing Apple has a lot of different "modes" that they can run binaries in, which can be a bit difficult to find your bearings in, but I've tried to be as thorough as I could in testing them all. Tested using roughly the equivalent of `./x test library/std -- platform_version` on the following configurations: - macOS 14.7.3 on a Macbook Pro M2 - `aarch64-apple-darwin` - `x86_64-apple-darwin` (under Rosetta) - `aarch64-apple-ios-macabi` - `x86_64-apple-ios-macabi` (under Rosetta) - `aarch64-apple-ios` (using Xcode's "Designed for iPad" setting) - `aarch64-apple-ios-sim` (in iOS Simulator, as iPhone with iOS 17.5) - `aarch64-apple-ios-sim` (in iOS Simulator, as iPad with iOS 18.2) - `aarch64-apple-tvos-sim` (in tvOS Simulator) - `aarch64-apple-watchos-sim` (in watchOS Simulator) - `aarch64-apple-ios-sim` (in visionOS simulator, using Xcode's "Designed for iPad" setting) - `aarch64-apple-visionos-sim` (in visionOS Simulator) - macOS 15.3.1 VM - `aarch64-apple-darwin` - `aarch64-apple-ios-macabi` - macOS 10.12.6 on an Intel Macbook from 2013 - `x86_64-apple-darwin` - `i686-apple-darwin` - `x86_64-apple-ios` (in iOS Simulator) - iOS 9.3.6 on a 1st generation iPad Mini - `armv7-apple-ios` with an older compiler Along with manually inspecting the output of `version_from_sysctl()` and `version_from_plist()`, and verifying that they actually match what's expected. I believe the only real omissions here would be: - `aarch64-apple-ios` on a newer iPhone that has `sysctl` available (iOS 11.4 or above). - `aarch64-apple-ios` on a Vision Pro using Xcode's "Designed for iPad" setting. But I don't have the hardware available to test those. `@rustbot` label O-apple A-linkage -T-compiler -A-meta -A-run-make try-job: aarch64-apple try-job: x86_64-apple*

rust-bors · 2025-06-13T16:33:43Z

☀️ Try build successful (CI)
Build commit: 7334def (7334def256dcd96dafe3a7c2db0126901ab7070f, parent: 015c7770ec0ffdba9ff03f1861144a827497f8ca)

rustbot assigned Amanieu Mar 25, 2025

madsmtm changed the title ~~Add __isOSVersionAtLeast and __isPlatformVersionAtLeast symbols~~ Add __isPlatformVersionAtLeast and __isOSVersionAtLeast symbols Mar 25, 2025

madsmtm mentioned this pull request Mar 25, 2025

Implement __isPlatformVersionAtLeast and __isOSVersionAtLeast rust-lang/compiler-builtins#794

Closed

This comment has been minimized.

Sign in to view

rustbot added the O-apple Operating system: Apple (macOS, iOS, tvOS, visionOS, watchOS) label Mar 25, 2025

madsmtm force-pushed the apple_os_version_check branch from 3908474 to 721f8eb Compare March 25, 2025 20:21

rustbot assigned tgross35 and unassigned Amanieu Apr 3, 2025

madsmtm mentioned this pull request Apr 4, 2025

Support "zippered" macOS binaries #131216

Open

madsmtm force-pushed the apple_os_version_check branch from 721f8eb to a0061ac Compare April 4, 2025 11:52

madsmtm mentioned this pull request Apr 4, 2025

How do we handle availability? madsmtm/objc2#266

Open

This comment has been minimized.

Sign in to view

madsmtm force-pushed the apple_os_version_check branch from a0061ac to 19cccaf Compare April 4, 2025 12:13

madsmtm added a commit to madsmtm/objc2 that referenced this pull request Apr 4, 2025

Fix available! macro when running in "Designed for iPad" mode

e1c7b20

Based on findings in rust-lang/rust#138944, we were previously incorrectly falling back to the product version of the host system.

tgross35 requested changes Apr 9, 2025

View reviewed changes

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 9, 2025

rustbot removed T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. A-meta Area: Issues & PRs about the rust-lang/rust repository itself labels Apr 9, 2025

tgross35 approved these changes Jun 12, 2025

View reviewed changes

library/std/src/sys/platform_version/darwin/core_foundation.rs Outdated Show resolved Hide resolved

madsmtm force-pushed the apple_os_version_check branch from 7852c5c to 516742a Compare June 12, 2025 23:29

madsmtm force-pushed the apple_os_version_check branch from 516742a to 5ec7157 Compare June 13, 2025 01:34

madsmtm force-pushed the apple_os_version_check branch from 5ec7157 to 779ac2f Compare June 13, 2025 11:46

Add __isOSVersionAtLeast and __isPlatformVersionAtLeast symbols

d543096

Allows users to link to Objective-C code using `@available(...)`.

madsmtm force-pushed the apple_os_version_check branch from 779ac2f to d543096 Compare June 13, 2025 14:17

Add __isPlatformVersionAtLeast and __isOSVersionAtLeast symbols #138944

Are you sure you want to change the base?

Add __isPlatformVersionAtLeast and __isOSVersionAtLeast symbols #138944

Conversation

madsmtm commented Mar 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Motivation

Solution

Testing

Uh oh!

rustbot commented Mar 25, 2025

Uh oh!

rustbot commented Mar 25, 2025

Uh oh!

This comment has been minimized.

Amanieu commented Apr 3, 2025

Uh oh!

tgross35 commented Apr 3, 2025

Uh oh!

This comment has been minimized.

Amanieu commented Apr 5, 2025

Uh oh!

tgross35 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

tgross35 Apr 8, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

tgross35 Apr 8, 2025

Choose a reason for hiding this comment

Uh oh!

madsmtm Apr 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

madsmtm Apr 9, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

madsmtm commented Apr 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tgross35 commented Jun 12, 2025

Uh oh!

rust-bors bot commented Jun 12, 2025

Uh oh!

rust-bors bot commented Jun 12, 2025

Uh oh!

tgross35 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

madsmtm commented Jun 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rust-bors bot commented Jun 12, 2025

Uh oh!

rust-bors bot commented Jun 13, 2025

Uh oh!

madsmtm commented Jun 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rust-bors bot commented Jun 13, 2025

Uh oh!

madsmtm commented Jun 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rust-bors bot commented Jun 13, 2025

Uh oh!

rust-bors bot commented Jun 13, 2025

Uh oh!

rust-bors bot commented Jun 13, 2025

Uh oh!

madsmtm commented Jun 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Add `isPlatformVersionAtLeast` and `isOSVersionAtLeast` symbols #138944

Add `isPlatformVersionAtLeast` and `isOSVersionAtLeast` symbols #138944

madsmtm commented Mar 25, 2025 •

edited

Loading

madsmtm Apr 9, 2025 •

edited

Loading

madsmtm commented Apr 9, 2025 •

edited

Loading

madsmtm commented Jun 12, 2025 •

edited

Loading

madsmtm commented Jun 13, 2025 •

edited

Loading

madsmtm commented Jun 13, 2025 •

edited

Loading

madsmtm commented Jun 13, 2025 •

edited

Loading

madsmtm commented Jun 13, 2025 •

edited

Loading